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Abstract 

Mobile  malware  is  growing  -  both  in  overall  volume  and  in  number  of  existing  variants  -  at  a  pace 
rapid  enough  that  systematic  manual,  human  analysis  is  becoming  increasingly  difficult.  As  a  result, 
there  is  a  pressing  need  for  techniques  and  tools  that  provide  automated  analysis  of  mobile  malware 
samples.  We  present  A5,  an  automated  system  to  process  Android  malware.  A5  is  a  hybrid  system  com¬ 
bining  static  and  dynamic  malware  analysis  techniques.  Android’s  architecture  permits  many  different 
paths  for  malware  to  react  to  system  events,  any  of  which  may  result  in  malicious  behavior.  Key  inno¬ 
vations  in  A5  consist  in  novel  methods  of  interacting  with  mobile  malware  to  better  coerce  malicious 
behavior,  and  in  combining  both  virtual  and  physical  pools  of  Android  platforms  to  capture  behavior  that 
could  otherwise  be  missed.  The  primary  output  of  A5  is  a  set  of  network  threat  indicators  and  intrusion 
detection  system  signatures  that  can  be  used  to  detect  and  prevent  malicious  network  activity.  We  detail 
A5’s  distributed  design  and  demonstrate  applicability  of  our  interaction  techniques  using  examples  from 
real  malware.  Additionally,  we  compare  A5  with  other  automated  systems  and  provide  performance 
measurements  of  an  implementation,  using  a  published  dataset  of  1,260  unique  malware  samples,  show¬ 
ing  that  A5  can  quickly  process  large  amounts  of  malware.  We  provide  a  public  web  interface  to  our 
implementation  of  A5  that  allows  third  parties  to  use  A5  as  a  web  service. 
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1  Introduction 


The  number  of  applieations  available  for  mobile  phones  and  tablets  has  surged  dramatically  over  the  past 
couple  of  years;  this  trend  has  been  particularly  pronounced  for  Android  devices,  that  now  represent  73% 
of  all  mobile  devices  [17].  Concomitant  with  this  rise  in  the  number  of  applications  available,  malware 
targeting  mobile  platforms,  and  specifically  Android,  has  also  started  to  appear  [16, 32,  39].  Even  though 
industry  reports  of  “exponential  growth”  in  mobile  malware  [13,23]  must  be  taken  with  a  grain  of  salt  [22] 
there  is  little  doubt  that  the  overall  volume  of  mobile  malware  is  increasing  at  a  pace  that  makes  it  difficult 
to  sustain  systematic  manual  analysis.  It  is,  therefore,  important  to  develop  automated  analysis  capabilities 
for  mobile  malware. 

Detecting,  analyzing  and  combating  mobile  malware  presents  a  number  of  unique  challenges.  First, 
different  from  the  situation  with  personal  computers,  users  generally  do  not  have  full  administrative  access 
to  their  mobile  device,  which  makes  it  much  more  challenging  to  develop  effective  anti-virus  tools.  Second, 
carriers  and  network  operators,  who  can  fairly  tightly  control  the  network,  may  have  only  limited  capabilities 
to  control  individual  devices.  Third,  techniques  useful  to  “sandbox”  potentially  harmful  applications,  such 
as  virtualization,  are  much  less  mature  on  mobile  devices  than  they  are  on  PCs. 

These  unique  challenges  suggest  that  traditional  malware  analysis  and  detection  methods  need  to  be 
rethought  in  the  context  of  mobile  devices.  For  mobile  devices,  network-based  identifiers  (e.g.,  nefwork 
fraffic  pafferns)  are  considerably  more  actionable  fhan  hosf-based  identifiers  (e.g.,  writing  a  specific  file). 
Indeed,  a  carrier  or  operafor  could  easily  disconnecf,  and  pofenlially  resef,  a  mobile  device  fhaf  produces 
suspicious  nefwork  fraffic.  On  fhe  ofher  hand,  defecting,  on  fhe  device  ifself,  fhaf  an  applicafion  is  malicious 
is  much  more  complex  wifhouf  elevated  privileges.  In  ofher  words,  given  fhe  currenf  adminisfrafive  models, 
nefwork-based  infrusion  detection  systems  appear  considerably  more  useful  fo  mobile  devices  fhan  fheir 
hosf-based  counferparfs. 

We  use  fhese  insighfs  fo  propose  “A5,”  shorf  for  Aufomafed  Analysis  of  Adversarial  Android  Appli- 
cafions.  A5  is  a  system  fhaf  draws  concepfual  design  from  existing  dynamic  analysis  (or  “sandbox”)  sys¬ 
tems.  Af  a  high  level,  A5  executes  malware  in  a  sandbox  environmenf  fhaf  consisfs  of  a  combination  of 
physical  devices  and  virfual  Android  sysfems  hosted  on  a  PC.  A5  allows  malware  fo  conned  fo  fhe  In- 
fernef,  in  order  fo  record  nefwork  fhreaf  indicafors  and  create  nefwork  infrusion  defecfion  system  (IDS) 
signafures.  These  signafures  can  in  furn  be  used  by  an  enferprise  fo  profecf  mobile  devices  fhaf  conned 
fo  fhe  Infernd  fhrough  a  corporate  nefwork  or  fo  profecf  all  corporate  devices  by  forcing  mobile  device 
fraffic  fhrough  a  nefwork  proxy.  Similarly,  cellular  providers  could  use  fhese  signafures  fo  profecf  devices 
connecfed  fo  carrier  nefworks.  We  provide  a  web-based  inferface  fo  our  currenf  implemenfafion  of  A5  af 
http : / / dogo . ece . emu . edu/a5. 

The  key  novelfy  in  A5  is  fo  use  a  combinafion  of  sfafic  and  dynamic  analysis  fo  coerce  fhe  application 
info  friggering  ifs  malicious  behavior.  Indeed,  in  mobile  applicafions,  adivify  can  be  friggered  by  a  wide  as- 
sorfmenf  of  system  evenfs  -  for  insfance,  receiving  a  phone  call,  or  having  fhe  screen  go  info  lock  mode.  A5 
affempfs  fo  exhaustively  determine  all  possible  pafhs  fhaf  can  frigger  malicious  behavior,  before  separafely 
evaluafing  fhem.  Doing  so,  A5  can  capfure  adivify  fhaf  would  be  missed  by  naively  execufing  fhe  malware 
(i.e.,  simply  “clicking  on  fhe  icon”).  Furfhermore,  by  combining  physical  devices  wifh  virfual  Android  im¬ 
ages,  A5  can  capfure  a  wider  range  of  malicious  behavior  fhan  a  sandbox  solely  based  on  emulation  would 
and  can  corredly  process  malware  fhaf  employs  cerfain  fype  of  sandbox  evasion  fechniques.  Fikewise,  A5 
can  accommodate  a  wide  range  of  differenl  hardware  and  soflware  (e.g.,  SDK)  configuralions. 

In  fhe  reminder  of  fhis  paper,  we  firsf  infroduce  background  on  sialic  and  dynamic  analysis  in  section  2, 
where  we  also  differenliate  A5  from  fhe  relalively  large  body  of  relaled  work  on  Android  securify.  We 
Ihen  describe  fhe  design  and  archileclure  of  A5  in  seclion  3.  We  presenf  a  performance  evalualion  of  our 
currenf  implemenfafion  of  A5  in  seclion  4,  nolably  showing  fhaf,  using  parallelism,  A5  is  able  fo  analyze 
1,260  unique  malware  samples  in  jusl  over  10  hours.  We  discuss  A5’s  limitations  in  section  5,  and  draw 


conclusions  in  section  6. 


2  Background  and  Related  Work 

Without  access  to  source  code  for  analysis,  inspection  and  understanding,  one  must  resort  to  other  techniques 
when  analyzing  compiled  software.  In  the  context  of  malware  analysis,  dynamic  analysis  involves  executing 
the  malware  samples  to  observe  their  behavior  [25] .  Conversely,  static  analysis  refers  to  techniques  that 
inspect  or  process  a  sample,  but  never  execute  the  malware  [14].  Manual,  static  analysis,  colloquially 
known  as  as  “reverse  engineering,”  can  be  very  effective,  but  often  requires  highly  trained  individuals  and  is 
time  consuming.  Thus,  it  is  difficult  to  scale  manual  analysis  at  the  pace  that  mobile  malware  is  growing  - 
both  in  terms  of  volume  and  in  number  of  existing  variants  [13, 16,23,32,39]. 

A  dynamic  analysis  technique  often  used  in  vulnerability  discovery  can  be  automated  to  process  input  to 
samples  automatically.  Fuzzing  is  the  process  of  sending  data  as  input  to  a  program,  possibly  intentionally 
invalid  data,  in  order  to  coerce  a  desired  condition  or  behavior.  The  input  can  be  created  programmatically 
to  cover  a  range  of  inputs,  and  in  this  way  can  be  thought  of  as  a  brute-force  attack  against  the  software. 
This  technique  may  be  considered  inelegant,  but  fuzzing  implementations  are  often  straight-forward,  and 
effective.  Fuzzing  is  used  in  automated  vulnerability  discovery  to  find  soffware  vulnerabilifies  fhaf  are  nof 
feasible  fo  audif  in  any  ofher  way  [29]. 

Malware  sandboxes.  Malware  sandboxes  automate  dynamic  analysis  techniques  fo  inspecf  large  volumes 
of  malware  aufomafically.  The  general  operation  of  a  sandbox  system  is  to  execufe  each  inpuf  sample 
much  like  a  user  would,  buf  in  a  confrolled  environmenf  insfrumenfed  fo  monifor  hosf  and  nefwork  acfiv- 
ify.  The  sheer  volume  of  unique  malware  samples  on  fradifional  compufers  makes  fhe  use  of  aufomafed 
sandboxes  appealing.  Numerous  commercial  producfs,  such  as  CWSandbox  [37],  and  academic  projecfs, 
such  as  ANUBIS  [6],  have  appeared  over  fhe  pasf  several  years.  Automated  sandboxes  oflen  scale  linearly 
wifh  compufafional  power.  A  sandbox  addressing  computer  malware  may  bool  a  virlual  machine,  copy  fhe 
samples  fo  fhe  virlual  machine,  Ihen  execute  fhe  sample.  The  sandbox  can  monifor  and  reporl  on  changes 
to  fhe  hosf  (i.e.,  regislry  keys,  files)  and  nefwork  communications.  For  instance,  Rossow  el  al.  present  a 
dynamic  analysis  system  called  Sandnet  [25],  which  is  used  to  collect  network  traffic  from  PC  malware 
samples.  Sandnel  is  used  to  process  100,000  samples  and  fhe  aulhors  find  lhal  DNS  and  HTTP  have  novel 
Irends  in  malware  use. 

Malware  analysis  systems  for  Android.  The  work  mosl  relafed  to  A5  is  a  dynamic  analysis  system  called 
Andrubis  [2].  Andrubis  is  an  exlension  to  fhe  aufomafed  PC  malware  analysis  projecl  ANUBIS,  buf  is 
designed  for  processing  Android  packages.  The  inner-workings  of  Andrubis  are  nof  publicly  known,  buf 
fhe  crealors  allow  anyone  fo  inleracl  wifh  a  public  inlerface  via  website.  Biasing  el  al.  [7]  describe  anofher 
dynamic  analysis  sysfem  for  Android.  Their  sysfem  focuses  on  classifying  inpuf  applications  as  malicious 
(or  nof).  The  sysfem  inslrumenls  Linux  fealures  and  scans  applications  for  fhe  use  of  pofenlially  dangerous 
criferia.  Like  Andrubis,  Ibis  sysfem  inleracls  wifh  fhe  malware  by  sfarfing  fhe  applicafion’s  primary  Acfivify. 

A5  differs  from  fhese  fwo  sysfems  primarily  in  fhe  way  A5  inleracls  wifh  fhe  malware — using  multiple 
techniques  to  coerce  fhe  execulion  of  fhe  malicious  code.  However,  Ihere  are  several  ofher  differences  such 
as  fhe  parallel  implemenlalion  of  A5,  supporl  for  every  Android  API  version,  and  fhe  abilily  fo  use  virlual 
inslances,  physical  devices  or  bolh. 

DroidBox  [21]  is  a  generic  app  monitoring  tool  for  Android  apps.  If  monilors  an  Android  app  for  various 
aclivilies  al  runtime,  such  as  incoming  and  oufgoing  nefwork  dala,  file  read  and  wrile  operalions,  services 
slarled,  elc.  If  Ihen  provides  a  limeline  view  of  fhe  monilored  acfivify  from  fhe  app.  DroidBox  is  useful 
for  manually  identifying  malware  by  viewing  ils  observed  behavior.  Compared  fo  A5,  DroidBox  does  nof 
aufomafically  coerce  fhe  app  into  underlaking  particular  behaviors,  and  A5  specifically  caplures  nefwork 
Iraffic  for  finding  malicious  nefwork  indicalors.  In  addition,  A5  uses  sialic-analysis  in  addilion  fo  dynamic 


monitoring  of  the  app  to  find  coercion  points  automatically. 

Similar  to  A5’s  bytecode  static-analysis,  ComDroid  [8]  performs  static-analysis  of  decompiled  bytecode 
of  Android  applications.  ComDroid  performs  flow-sensitive,  intra-procedural  analysis  to  find  Android  “In¬ 
tents”  sent  with  weak  or  no  permissions — ^but  contrary  to  A5,  ComDroid  does  not  perform  any  dynamic 
analysis. 

A5  currently  only  captures  network  traffic  to  aid  in  finding  malicious  network  indicators.  It  may  make 
sense  to  pair  A5  with  taint  tracking  systems  such  as  TaintDroid  [10]  in  order  to  track  host-based  malware 
indicators.  For  instance,  Andrubis  employs  TaintDroid.  However,  it  may  take  significant  effort  to  extend 
TaintDroid  to  support  all  SDK  target  versions  and  to  work  with  a  range  of  physical  devices,  as  A5  does  right 
now. 

Automated  signature  creation.  Automating  the  tedious  and  error-prone  process  of  creating  network  IDS  sig¬ 
natures  is  a  well  researched  topic  but  remains  an  open  problem.  As  a  representative  example,  Kim  and  Karp 
create  an  automated  system  call  Autograph  that  generates  signatures  for  TCP-based  Internet  worms  [19]. 
Like  many  efforts  at  automatic  signature  creation.  Autograph’s  detection  mechanisms  are  particularly  de¬ 
signed  to  address  one  type  of  malware,  in  this  case  worms.  As  such.  Autograph’s  pre-filtering  step  that 
discerns  unsuccessful  TCP  connections,  is  not  particularly  useful  for  identifying  malicious  Android  applica¬ 
tion  traffic.  A  different  system  called  Honeycomb  presents  similarities  to  A5’s  desired  goal  of  automatically 
creating  IDS  signatures.  Kreibich  and  Crowcroft  describe  the  system  which  collects  traffic  from  a  honeypot 
and  subsequently  creates  network  signatures  [20] .  Since  the  network  traffic  is  captured  from  a  honeypot,  the 
traffic  is  assumed  to  be  malicious  (or  at  least  suspicious).  A5  similarly  assumes  that  all  input  is  malware,  but 
due  to  the  repackaging  common  in  Android  malware,  malicious  network  traffic  is  likely  to  be  mixed  with 
benign  traffic. 

3  A5  architecture 

The  immediate  need  for  a  system  like  A5  is  driven  by  increasing  volumes  of  mobile  malware.  However,  the 
design  of  A5  is  also  directed  by  several  criteria  borrowing  from  the  more  mature  field  of  PC-based  dynamic 
analysis  and  the  unique  nature  of  today’s  mobile  device  ecosystem.  Here  we  enumerate  a  list  of  desired 
features  for  such  a  system,  and  describe  an  implementation  designed  to  meet  these  goals. 

3.1  Objectives  and  Design 

Autonomy  and  scalability.  The  system  must  be  able  to  handle  volumes  of  malware  without  user  interac¬ 
tion.  As  with  PC  malware,  mobile  malware  is  now  growing  at  a  rate  that  makes  manual,  human  analysis 
unfeasible. 

Evasion  resistance.  The  system  must  be  able  to  adapt  to  evasion  advances  in  malware.  As  seen  in  the  PC, 
mobile  malware  is  increasing  in  sophistication.  With  the  advent  of  automated  malware  processing,  malware 
authors  have  already  begun  to  include  minor  attempts  to  evade  sandbox  systems. 

Mobile-specific  interaction.  The  system  must  interact  with  malware  in  Android-specific  ways.  It  is  indeed 
more  difficult  to  solicit  malicious  behavior  from  current  mobile  malware,  than  traditional  malware.  Simply 
executing  the  malware  (i.e.,  “clicking  on  the  icon”)  may  not  exhibit  any  malicious  behavior.  Indeed,  current 
mobile  operating  systems  permit  applications  to  register  a  software  handler  for  a  wide  range  of  system 
events;  for  instance,  receiving  an  SMS,  screen  going  in  lock  mode,  and  so  forth.  Any  such  event  may  trigger 
some  application  code.  Traditional  computer  programs  may  receive  input  along  with  execution;  mobile 
applications  may  receive  input  along  with  a  myriad  of  system  events.  In  either  case,  the  behavior  may 
depend  upon  the  input  to  the  application. 
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Figure  1:  A5  architecture.  Malware  is  first  ingested  (1)  into  a  shared  job  queue.  Independently,  an  overall  controller 
is  started  (2)  which  starts  one  or  more  Worker  processes  (3).  Each  Worker  retrieves  jobs  from  the  queue  (4)  and  either 
postpones  work  or  reserves  a  device  instance  (5)  for  dynamic  analysis  (6).  Once  analysis  is  complete,  the  device  is 
returned  to  the  ready  pool  (7).  There  may  be  many  Workers  and  Device  Pools  on  a  single  host.  The  controller  and  job 
queue  may  service  many  hosts  (each  with  many  Workers). 


Network-level  indicator  collection.  The  system  should  primarily  collect  network  threat  indicators.  Host- 
based  indicators,  such  as  the  modification  of  a  file  found  on  the  device,  are  of  limited  value  on  Android. 
Indeed,  since  Android’s  architecture  does  not  permit  file  system  hooks,  and,  more  generally  does  not  even 
permit  privileged  access  to  most  components  of  the  system,  it  is  not  possible  to  implement  controls  similar 
to  anti-virus  products  found  on  the  PC.  Even  if  Android’s  architecture  were  adapted  to  permit  such  products 
(e.g.,  by  systematically  “rooting”  devices),  network  indicators  are  particularly  useful  to  cellular  carriers 
and/or  wireless  network  operators  to  protect  the  device  even  without  the  ability  to  install  controls  on  the 
device  itself. 

Modularity.  The  system  should  have  a  modular,  expandable  design.  Mature  analysis  systems  need  to  have 
interfaces  allowing  for  the  system  to  interact  with  other  software  systems  such  as  intrusion-detection  sys¬ 
tems  (IDS)  or  firewall  management  tools.  This  requirement  is  generally  driven  by  entities  that  have  larger 
research  and  analysis  environments  of  which  A5  may  become  a  component.  Additionally,  the  system  must 
be  generally  able  to  adapt  to  unforeseen  circumstances,  such  as  malware  that  exhibits  some  new  behavior  or 
technology  that  was  not  yet  imagined  when  the  system  was  designed. 

Based  on  these  objectives,  we  made  the  following  design  choices  for  the  A5  architecture.  To  process 
as  much  malware  as  possible,  A5  is  highly  parallel  and  distributed.  The  basic  steps  involved  are  shown 
in  Figure  1  and  detailed  in  the  following  sections.  A5  consists  of  a  queue,  a  main  controller,  and  a  set 
of  workers  which  interact  with  a  pool  of  device  instances  -  these  device  instances  are  a  combination  of 
hardware  resources  (e.g.,  a  specific  phone  model),  and  Android  images  running  as  virtual  machines  on  a 
traditional  PC. 

First,  malware  is  moved  into  the  system  and  two  stages  of  static  analysis  are  performed  to  determine 
methods  of  interacting  with  the  malware.  Once  static  analysis  is  complete,  an  entry  is  created  in  a  job  queue 


for  subsequent  dynamie  analysis.  Later,  one  of  many  worker  proeesses  retrieves  the  job  from  the  shared 
queue  and  exeeutes  the  malware  using  an  available  deviee  from  the  deviee  pool.  The  dynamie  analysis  is 
informed  from  the  statie  analysis;  this  eombination  of  statie  and  dynamie  analysis  allows  our  system  to 
better  eoeree  malware  to  exeeute  nefarious  behavior. 

The  remainder  of  this  seetion  details  the  implementation  of  A5.  In  partieular,  eaeh  of  stage  1  statie 
analysis,  stage  2  statie  analysis,  and  dynamie  analysis  are  detailed.  Then,  the  eoneept  of  deviee  pools 
eonsisting  of  virtual  and  physieal  deviees  is  deseribed,  followed  by  a  diseussion  of  some  Android-speeifie 
interaetion  teehniques. 

3.2  Malware  Ingestion 

A5  assumes  all  input  samples  are  malware.  The  primary  funetions  of  the  ingestion  proeess  are  to  ereate  a 
shared  job  queue  entry,  (we  use  beanstalkd^),  to  ealeulate  several  pieees  of  meta-data  (sueh  as  eryptographie 
hash  values),  and  to  initiate  the  statie  analysis. 

A5’s  ingest  proeess  is  designed  to  run  on  eaeh  individual  sample.  This  allows  for  on-demand  sub¬ 
mission,  sueh  as  what  one  may  expeet  of  a  web  serviee,  and  as  a  batehed  proeess  running  periodieally, 
eonsuming  samples  that  are  plaeed  in  a  partieular  system  path.  This  allows  all  of  A5  to  run  perpetually  with 
no  interaetion  from  a  user.  Many  seeurity  eompanies  reeeive  thousands  of  samples  daily  from  sourees  sueh 
as  VirusTotal  [35]  or  MWColleet  [36].  These  ineoming  samples  ean  easily  be  sorted,  for  example,  to  eolleet 
all  Android  samples  in  one  loeation  for  input  into  A5. 

3.3  Static  Analysis 

A5  first  resorts  to  statie  analysis  to  try  to  deteet  potentially  malieious  aetions.  In  Android,  applieations 
are  usually  written  in  Java  (less  than  5%  have  “native”  C  eomponents  [40]),  and  are  distributed  as  APK 
(Android  paekage)  files.  These  APK  files  are  in  faet  Zip  arehives,  whieh  eontain  eompiled  Java  elasses  (in 
Dalvik  DEX  format),  applieation  resourees,  and  an  AndroidManif  est .  xml  binary  XML  file  eontaining 
applieation  meta-data.  The  strueture  of  Android  applieations  and  the  Android  seeurity  meehanisms  have 
been  well-doeumented  [12,27]  and  many  tools  exist  for  ereating  and  manipulating  APKs  [3,5]. 

Typieally,  Android  applieations  that  have  a  user  interfaee  speeify  at  least  one  Android  Activity  and  those 
that  do  not  have  a  user  interfaee  speeify  at  least  one  Service.  These  are  elasses  that  typieally  eontain  the  eore 
funetionality  of  the  mobile  applieation,  and  are  the  primary  method  for  exeeuting  applieation  eode.  Mueh 
of  the  interaetion  with  an  Aetivity  will  be  through  the  Graphieal  User  Interfaee  (GUI).  However,  a  Serviee 
may  exhibit  no  GUI  eomponents  at  all,  requiring  different  interaetion  during  later  dynamie  analysis. 

Android  Inter-Proeess  Communieation  (IPG)  typieally  oeeurs  in  the  form  of  an  Android  event  known 
as  an  Intent.  For  instanee.  Intents  are  used  to  transfer  information  between  applieations  and  to  notify  appli¬ 
eations  when  a  partieular  system  event,  sueh  as  the  reeeipt  of  a  text  message,  has  oeeurred.  Sinee  Android 
Serviees  have  no  GUI,  it  is  preeisely  these  types  of  events  that  initiate  a  Serviee. 

The  ehief  output  of  statie  analysis  is  an  enumeration  of  “interaetion  points”  (e.g.  Aetivities)  and  a  set 
of  “reeeivable  intents”  (e.g.  BOOT_COMPLETED).  Any  of  these  may  eause  the  applieation  to  take  aetions 
that  would  not  normally  oeeur  if  the  applieation  was  simply  launehed  using  the  graphieal  interfaee.  As  sueh, 
A5  will  use  these  sets  in  order  to  eoeree  behavior  from  the  malieious  applieation.  Many  of  these  meet  the 
need  for  better  mobile-speeifie  interaetion. 

'beanstalkd  can  be  found  at  http  :  /  /kr  .  github  .  com/beanstalkd/  and  is  described  as  “a  simple,  fast  work  queue” 
originally  designed  to  reduce  latency  on  high-volume  websites. 


1  <receiver 

2  android;name=”  .  message  .  SmsReceiver” 

3  androi d ; en abled=” true ” 

4  androi d ;  exported  =  ”  true  ”  > 

5  <intent— filter 

6  android:priority=”214783648”  > 

7  <action 

8  android;name  =  ”  android  .  provider  .  Telephony  .  SMSJRECEIVED”  > 

9  </  action> 

10  </ intent —filter> 

11  </ receiver> 


Figure  2:  Receiver  from  ANDROID-DOS  malware.  A5  notes  the  action  for  this  receiver.  Receipt  of  a  text  message 
may  be  the  only  way  this  method  is  executed.  In  other  words,  the  .message  .  SmsReceiver  code  may  never  be 
invoked  if  the  instance  never  receives  a  text  message. 


3.3.1  Stage  1  Static  Analysis:  AndroidManifest 

Much  of  the  stage  1  analysis  in  A5  revolves  around  the  AndroidManifest .  xml  file.  This  file  dicfafes 
much  of  how  an  applicafion  may  inferacf  wifh  fhe  device.  Each  applicafion  musf  adverfise  fhe  desire  fo 
receive  parficular  Infenfs  by  declaring  permissions  in  fhe  AndroidManifesl.  Similarly,  fhrough  documenfa- 
fion  [34]  and  source  code  analysis  [15],  use  of  cerfain  API  funclions  implies  fhe  abilify  fo  receive  cerfain 
Infenfs. 

Even  fhough  fhe  manifesf  is  sfored  in  binary  XME  form,  fools  are  readily  available  for  parsing  key 
componenfs  such  as  requesfed  permissions,  broadcasf  receivers,  background  services,  and  acfivifies.  Each 
of  fhese  componenfs  define  key  inferacfion  poinfs  for  fhe  applicafion,  and  are  cafaloged  for  lafer  use  in 
dynamic  analysis. 

Eor  insfance,  an  Android  BroadcastReceiver  or  “receiver”  is  a  way  for  an  applicafion  fo  regisfer 
fhe  desire  fo  receive  an  Infenf  from  fhe  sysfem  or  anofher  applicafion  .  A  receiver  from  recenf  Android 
malware  is  shown  in  Eigure  2.  A5  parses  and  saves  fhe  action  from  Ibis  portion  of  fhe  manifesf,  in  fhis  case 
receipf  of  an  SMS  message.  During  dynamic  analysis,  fhe  receipf  of  a  fexf  message  may  be  fhe  only  action 
fhaf  invokes  fhe  .message  .  SmsReceiver  mefhod. 

Instead  of  creafing  yef-anolher-fool  fo  exfracf  perfinenf  informalion,  we  elecfed  fo  leverage  an  existing 
open  source  fool  known  as  Androguard  [1].  If  Androguard  did  nol  supporf  a  parficular  funclion  fhaf  A5 
required,  we  implemenfed  fhe  fealure  and  submilled  pafches  back  fo  fhe  Androguard  developers. 

3.3.2  Stage  2  Static  Analysis:  Bytecode 

In  addition  to  the  relatively  naive  stage  1  analysis  of  the  Android  application  manifest,  we  also  analyze  the 
Java  bytecode  of  the  application  binaries.  The  goal  of  this  stage  2  static  analysis  is  to  identify  additional 
interaction  points  which  enable  users  or  the  system  to  interact  with  the  application.  While  many  interaction 
points  are  declared  in  the  application  manifest,  some  may  be  created  dynamically  by  the  application,  thus 
being  missed  by  naive  analysis. 

An  example  of  an  interaction  point  that  may  be  missed  during  stage  1  is  shown  in  Eigure  3.  The  appli¬ 
cation  in  Eigure  3  performs  a  registerReceiver  call  registering  the  desire  to  be  notified  when  either 
the  user  begins  interacting  with  the  device  or  the  device  screen  turns  off.  Neither  of  these  Intents  are  found 

in  the  AndroidManifest .  xml. 


1  public  static  void  h(Context  paramContext ) 

2  { 

3  IntentFilter  localIntentFilter  =  new  IntentFilter(); 

4  localIntentFilter  .  addAction(”  android  .  intent  .  action  .  USERJPRESENT”  )  ; 

5  localIntentEilter  .  addAction(”  android  .  intent  .  action  .  SCREEN  _OFF” )  ; 

6  paramContext .  registerReceiver  (new  User ActivityReceiver  ()  , 

localIntentEilter ) ; 

7  return  ; 

8  } 


Figure  3:  Code  section  reverse  engineered  from  a  GoldDream  malware  sample.  Here,  the  desire  to  receive 
USER_PRESENT  and  SCREEN_OEE  Intents  are  registered  dynamically  -  these  Intents  do  not  appear  in  the  An- 
droidManifest.xml  and  would  be  missed  by  analysis  techniques  that  do  not  incorporate  bytecode  level  analysis. 

1  Calendar  c  =  Calendar  .  getinstance  ()  ; 

2  String  bootc  =  ”  android  .  intent  .  action  .BOOT_COMPLETED”  ; 

3  int  seconds  =  c  .  get  (  Calendar  .SECOND)  ; 

4  intentEilter  bootcif  =  new  intentEilter  (bootc); 

5  re gi  s  t erRe c e i  V er  (  b oot c if  )  ; 


Figure  4:  Code  section  demonstrating  the  need  to  resolve  variables.  In  this  case  the  CFG  is  recursively  traversed  in 
order  to  find  the  value  of  bootcif  at  the  time  registerReceiver  is  called  in  line  5.  In  this  case,  A5  concludes  that 
the  program  dynamically  registered  the  desire  to  be  notified  when  the  system  has  finished  booting. 


The  stage  2  statie  analysis  algorithm  is  fairly  intuitive.  First,  A5  invokes  the  DED  [11]  deeompiler  to 
ereate  Java  elasses  from  the  Android  applieation  eode.  Next,  A5  uses  Soot  [30]  to  obtain  an  Intermediate 
Representation  (IR)  and  a  Control  Flow  Graph  (CFG).  This  abstraet  IR  is  known  as  Jimple  [31]  and  is  useful 
because  it  eases  the  burden  of  dealing  with  the  more  complex  Java  bytecode. 

Each  node  in  the  CEG  represents  one  Java  statement,  and  the  graph  edges  correspond  to  the  relationship 
between  the  statements  in  the  malware.  A5  traverses  the  CEG  in  order  to  find  nodes  that  represent  a  known 
Android  interaction  point. 

Each  CEG  node  is  further  decomposed  into  an  Abstract  Syntax  Tree  (AST)  representing  individual 
components  of  the  statement.  Specifically,  A5  looks  for  calls  fo  android,  content .  Context .  reg¬ 
isterReceiver  ( )  and  android .  app .  Activity  .  startActivityForResult  {) .  Calls  fo 
android .  content .  Context .  registerReceiver  ( ) ,  as  shown  in  line  6  of  Eigure  3,  resulf  in  fhe 
application  becoming  eligible  fo  receive  Infenfs  wifh  a  specified  Action  (i.e.  a  particular  siring).  Similarly, 
calls  fo  android .  app  .  Activity .  startActivityForResult  ( )  resulf  in  fhe  application  making 
a  call  fo  anolher  application,  bul  wifh  an  embedded  Inlenl  for  fhe  callee  fo  make  a  callback  fo  fhe  largel 
application.  When  A5  discovers  one  of  Ihese  calls,  fhe  CEG  is  recursively  Iraversed  in  order  fo  resolve 
variable  definitions.  These  definifions  musl  be  resolved  in  order  fo  caplure  Infenfs  lhaf  represenl  inleraclion 
poinfs.  Eor  example,  Eigure  4  shows  a  call  fo  registerReceiver  al  tine  5,  however,  fhe  AST  node  only 
conlains  fhe  componenl  for  variable  bootcif.  A5  recursively  Iraverses  fhe  CEG  fo  delermine  fhe  variable 
definifion  al  tine  2. 

Much  tike  fhe  slage  1  sialic  analysis,  fhe  oulpul  of  fhe  bylecode  sfalic-analysis  is  a  sel  of  receivable 
Infenfs  for  use  during  fhe  dynamic  analysis. 


3.4  Dynamic  Analysis 


The  ingestion  process  and  static  analysis  components  execute  relatively  quickly,  but  the  dynamic  analysis 
portion  is  more  time-consuming.  Fortunately,  it  also  lends  itself  to  parallel  execution.  Figure  1  depicts 
many  workers  on  a  single  A5  host.  Worker  processes  on  each  A5  host  retrieve  jobs  from  the  shared  job 
queue  for  processing.  Once  a  new  job  has  been  reserved  from  the  queue,  the  Worker  inspects  a  pool  of 
candidate  Android  instances  available  to  that  particular  host  attempting  to  reserve  a  compatible  instance. 
A  compatible  instance  is  one  in  which  the  malware  sample  is  expected  to  run.  For  example,  a  mobile 
application  that  declares  a  minimum  SDK  (Android  API)  level  of  8,  will  not  run  on  a  level  4  device.  Even 
if  the  application  were  to  be  modified  by  A5  to  specify  level  4  prior  to  instance  selection,  the  application 
may  actually  rely  upon  a  feature  not  available  until  level  8.  Assuming  a  compatible  instance  is  available,  the 
Worker  continues  with  dynamic  analysis.  If  no  compatible  device  is  available,  the  job  is  placed  back  into 
the  queue  with  a  delay  in  order  to  reduce  the  chances  that  Workers  repeatedly  reserve  the  same  job  when  no 
compatible  instance  is  available  -  effectively  de-prioritizing  other  pending  samples. 


For  N  workers  on  each  machine: 


Figure  5:  Worker  process  flow.  Communication  with  the  device  instance  is  performed  using  the  Android  Debug 
Bridge  (ADB),  and  output  from  the  static  analysis  is  utilized  in  dynamic  analysis  interaction. 

The  Worker  then  boots  the  instance  and  follows  the  process  depicted  in  Figure  5.  Communication  with 
a  running  instance  is  performed  with  the  SDK  debugging  tool  known  as  the  Android  Debug  Bridge  (ADB)^. 
Since  the  boot  may  take  some  time,  the  worker  initiates  the  boot  process,  then,  using  ADB,  blocks  until  the 
device  is  fully  booted.  Once  booted,  A5  uses  ADB  to  install  the  malware  sample  into  the  instance.  Once  the 
sample  is  installed,  the  Worker  coerces  malicious  behavior  from  the  instance,  again  using  ADB.  After  a  set 
period  of  time  the  Worker  terminates  the  instance  and  returns  it  to  a  known  state. 

3.5  Instance  Pools 

When  retrieving  a  new  job,  the  Worker  must  locate  a  device  instance  compatible  with  the  malware  sample. 
For  this  reason,  A5  maintains  pools  of  devices  on  each  host.  Each  instance  in  the  pool  may  be  a  physical  or 
virtual  instance,  as  detailed  below.  Workers  synchronize  the  use  of  instances  by  maintaining  instance  state 
in  a  data  structure  shared  among  Workers  on  each  host. 

Virtual  instances  have  the  benefits  of  being  low-cost,  easy  to  automate  and  generally  flexible.  On  fhe 
ofher  hand,  virtual  devices  are  nol  fypically  used  in  everyday  compufing,  so  malware  fhaf  can  defecf  fhe 

^http : / /developer . android. com/ tools /help/ adb . html 


virtual  environment  may  eleet  to  exhibit  alternate  behavior.  In  this  light,  the  use  of  physieal  deviees  may  be 
warranted. 


3.5,1  Virtual  Instances 

Virtual  instanees  in  A5  are  realized  with  modified  versions  of  the  emulator  distributed  with  the  Android 
SDK.  These  instanees  all  are  are  stored  and  exeeuted  on  eommodity  eomputer  hardware.  Using  virtual 
instanees  allows  A5  to  seale  easily  by  simply  ereating  larger  instanee  pools  as  needed.  Resetting  a  vir¬ 
tual  instanee  to  a  known  state  is  as  simple  as  starting  the  instanee  with  a  “wipe  data”  flag  or  deleting  and 
reereating  the  instanee  image  from  serateh. 

However  the  emulator  offers  a  subset  of  features  found  on  a  real  deviee.  The  laek  of  features  ean  be 
eoarsely  grouped  into  two  elasses:  features  not  implemented  by  the  emulation  system  and  software  that  is 
not  present  in  the  emulated  deviee  image.  An  example  of  the  former  is  Bluetooth,  whieh  is  not  implemented 
in  the  emulator,  but  is  present  on  most  deviees.  An  example  of  the  latter  is  the  Google  Play  applieation, 
whieh  is  pre-installed  in  nearly  every  Android  deviee  sold,  but  is  not  present  in  the  default  emulated  deviee 
image. 

The  laek  of  features  presents  a  fundamental  problem  to  a  dynamie  analysis  system:  if  malware  makes 
use  of  one  these  missing  features,  the  malware  will  not  run  properly.  This  ehange  in  behavior  may  be  ex- 
plieit  (malware  employs  “virtualization  deteetion”)  or  implieit  (the  malware  happens  to  try  to  use  a  missing 
feature).  In  either  ease,  the  desired  behavior  from  the  sample  will  not  be  realized. 

On  traditional  eomputers,  virtualization  deteetion  was  initially  not  found  at  all.  It  was  later  employed 
more  frequently  to  evade  dynamie  analysis  systems:  If  the  malware  was  deteeting  it  was  running  on  a  virtual 
maehine,  the  malware  would  demonstrate  benign  behavior.  The  inereased  use  of  virtualization  deteetion  by 
malware  in  turn  led  to  ereating  dynamie  systems  employing  physieal  maehines  [28].  However,  as  virtual 
maehines  and,  more  generally,  virtualization,  is  inereasingly  employed  on  laptops  and  desktop  eomputers, 
running  in  a  virtual  maehine  is  not  a  give-away  that  the  platform  is  attempting  to  analyze  a  pieee  of  malware. 
In  other  words,  new  forms  of  malware  may  paradoxieally  employ  virtualization  deteetion  less  frequently. 

In  today’s  mobile  eomputing  paradigm,  the  deviees  physieally  move  with  the  user  and  data  bandwidth  at 
any  given  time  varies  greatly.  Contrary  to  traditional  eomputing  platforms,  there  is  not  yet  a  elear  use-ease 
for  virtualization  in  typieal  end-user  environments.  Resourees  sueh  as  bandwidth  or  power  are  far  more 
eonstrained  and  deviees  are  typieally  not  shared  among  multiple  users.  However,  if  systems  like  A5  are 
inereasingly  deployed  -  as  we  believe  they  will  be  -  virtualization  deteetion  in  mobile  malware  will  beeome 
a  reality. 

Manual  analysis  of  malware  families  in  2012  [39]  revealed  that  the  eurrent  generation  of  mobile  malware 
does  not  yet  employ  virtualization  deteetion.  Even  so,  Vidas  and  Christin  explored  possible  methods  sueh 
deteetion  might  be  implemented  and  provided  a  taxonomy  of  several  methods  [33].  Following  this  work, 
reeent  malware  is  starting  to  employ  sueh  deteetions  “in-the-wild”.  For  instanee,  a  reeent  Android  Malware 
(Jan  21,  2014),  Android.hehe  [9],  implements  two  eheeks:  (1)  the  nonexistanee  of  an  IMSI  -  a  unique 
eellular  subseriber  numer  and  (2)  the  existanee  of  Build,  strings  that  are  exaetly  “sdk”  or  “google _sdk” 
as  shown  in  Figure  6.  Similarly,  Android  Malware  ’’Oldboot”  (Apr  2,  2014)  identifies  is  running  loeation  of 
the  malware  instanee  (/  sbin/meta_chk)  and  exits  if  the  path  is  not  as  expeeted  or  if  there  is  no  sim  eard 
present. 

In  A5,  the  emulator  software  is  built  from  souree,  and  subsequently  the  resulting  emulator  is  sim¬ 
ilar  to  the  emulator  distributed  with  the  binary  Android  SDKs.  However,  we  enhaneed  the  emulator 
to  evade  some  virtualization  deteetion  features.  For  example,  an  unmodified  emulator  will  always  re¬ 
turn  the  same  values  for  APK  calls  such  as  TelephonyManager .  getDeviceld  ( )  (all  zero’s)  or 
Settings  .  Secure  .  ANDROID.ID  (null).  By  modifying  the  virtual  instances  such  that  values  indicating 
a  physical  rather  than  a  virtual  device  is  in  use,  A5  becomes  less  detectable  by  malware  seeking  to  deter- 


1  String  vO  =  Telephony  Utils  .  getimsi  (((  Context )  t  hi  s  ))  ; 

2  if(vO  ==  null)  { 

3  return  ; 

4  } 

5 

6  public  static  boolean  isEmulator()  { 

7  boolean  vO ; 

8  if  ((  Build  .MODEL.  equalsIgnoreCase  (”sdk”) )  ||  (  Build  .MODEL. 

equalsIgnoreCase(”google_sdk”)))  { 

9  vO  =  true  ; 

10  } 

11  else  { 

12  vO  =  false  ; 

13  } 

14  return  vO ; 

15  } 


Figure  6:  Simple  evasions  are  starting  to  appear  in  real  malware  observed  “in-the-wild.”  This  example  is  from 
Android. hehe  malware,  which  attepts  to  evade  analysis  by  detecting  that  an  instance  is  an  emulator  via  Build  strings 
common  in  developer  SDKs,  and  by  checking  for  the  lack  of  a  device  subsciber  ID  which  is  common  in  the  Android 
emulator. 

mine  if  execution  is  occurring  in  a  virtual  sandbox.  A5  makes  such  changes  in  Build  parameters,  the 
TelephonyManager  class,  and  the  default  networking  configuration.  A5’s  emulator  instances  have  con¬ 
figurable  sellings  in  Ihese  cases  each  inslance  relurns  values  lhal  simulale  values  observed  on  real  devices. 

However,  even  wilh  modificalions  lhal  make  Ihe  emulated  Android  inslance  more  like  a  physical  device, 
Ihere  are  large  voids  in  Ihe  emulated  environment  Malware  need  only  check  for  one  of  Ihe  many  hardware 
fealures  nol  currenlly  implemented  such  as  Blueloolh,  Wi-Fi,  sensors,  elc.  These  hardware  fealures  are  very 
common  in  physical  devices  and  are  simply  nol  presenl  in  Ihe  emulator.  Implemenling  entire  systems  to 
emulate  Ihese  is  a  large  underlaking  and  has  nol  been  done  as  pari  of  Ihe  currenl  A5  implemenlalion.  For 
Ihis  reason,  il  is  currenlly  Irivial  for  malware  to  delecl  lhal  Ihe  malicious  application  is  currenlly  running  in 
a  virlual  environmenl  and  nol  a  real  device.  To  address  Ihis  issue,  we  complemenl  our  virlual  environment 
with  physical  device  pools. 

3.5.2  Physical  Instances 

By  using  real,  physical  devices  in  A5  device  pools,  we  prevent  malware  from  being  able  to  trivially  de¬ 
termine  from  hardware  presence  that  the  sample  is  being  processed  by  a  dynamic  analysis  system.  The 
real  devices  possess  actual  hardware  for  systems  that  are  missing  in  the  virtualized  environment,  such  as 
Bluetooth.  A5  systems  relying  upon  physical  instances  can  scale  linearly  by  purchasing  more  devices. 

Physical  devices  embody  a  wide  range  of  software  features  and  hardware  capabilities.  As  with  typical 
computers,  more  recent  devices  have  more  computing  power  and  are  distributed  with  more  recent  software. 
In  order  to  process  all  samples  with  physical  devices,  at  least  one  device  is  needed  for  every  Android  SDK 
target  version. 

Resetting  a  physical  device  to  a  known  state  is  not  as  simple  as  resetting  a  virtual  instance.  Android 
devices  do  not  typically  have  boot  modes  that  can  be  controlled  remotely,  such  as  PXE  found  on  many  mod¬ 
ern  network  adapters.  In  fact,  typically  the  only  boot-time  interface  to  Android  devices  is  the  USB/charging 


port.  Various  manufacturers  support  proprietary  flashing  protocols,  but  some  devices  employ  the  more  ap¬ 
proachable protocol.  Critically  for  A5,  fastboot  supports  erasing  from  and  writing  to  device  data 
partitions.  A  device  may  enter  fastboot  mode  prior  to  loading  the  operating  system  when  a  person  uses  a 
special  hardware  key  combination.  However,  ADB  can  also  be  used  to  reboot  a  running  device  directly  into 
fastboot  mode.  In  this  way  A5  can  programmatically  return  a  physical  device  to  known  state  prior  to  each 
execution.  In  order  to  write  data  to  a  partition,  the  device  must  be  “unlocked.”  Manufacturers  each  have  dif¬ 
ferent  positions  on  whether  a  consumer  should  have  the  ability  to  write  data  to  a  device.  Developer-friendly 
devices,  such  as  the  Nexus-branded  devices,  can  all  easily  be  unlocked.  Similarly,  these  devices  also  support 
fastboot  making  them  ideal  devices  for  automated  use  in  A5. 

Unlike  virtual  devices,  physical  devices  are  capable  of  actual  physical  medium  communication.  Physical 
devices  can  communicate  over  cellular,  Wi-Fi,  Bluetooth,  NFC,  etc.  To  permit  devices  to  exhibit  network 
behavior,  A5  devices  are  configured  to  connect  to  a  wireless  access  point  that  routes  to  the  Internet.  This 
wireless  connection  provides  a  method  for  for  network  package  capture,  but  can  also  leak  sensitive  informa¬ 
tion  or  be  used  by  a  miscreant  to  attack  a  local  resource.  Furthermore,  the  wireless  environment  around  the 
device  may  change  due  to  outside  circumstances.  For  example,  a  neighbor  may  install  a  new  wireless  access 
point  to  which  the  device  may  connect.  For  all  of  these  reasons,  physical  device  pools  should  be  placed  into 
an  radio  frequency  (RF)  isolated  environment  along  with  the  routing  access  point. 

3.6  Malware  Interaction 

Regardless  of  the  instance  type,  once  the  malware  is  installed,  A5  must  interact  with  the  instance  to  coerce 
the  malicious  behavior.  Of  course,  A5  can,  and  does,  start  the  main  activity  of  applications  that  place  an 
icon  in  the  application  list  for  users  to  click.  However,  A5  employs  other  techniques  for  interaction. 

The  primary  method  for  interaction  is  via  receivable  Intents  ascertained  during  stage  1  and  stage  2  static 
analysis  as  described  in  sections  3.3.1  and  3.3.2.  Using  ADB,  a  Worker  can  send  intents  to  a  running 
instance.  Intents  are  sent  to  the  device  sequentially  and  feedback  from  ADB  can  be  used  to  verify  that  an 
Intent  was  successfully  registered  on  the  instance. 

A5  could  simply  send  every  type  of  Intent  available  for  the  SDK  version  of  the  instance.  However,  this 
coarse  style  of  fuzzing  presents  two  problems:  inability  to  discern  custom  Intents  and  poor  performance. 
Each  version  of  the  SDK  specifies  dozens  of  Intents  and  permissions  [4],  simply  iterating  through  all  of  these 
takes  considerable  time  which  would  lower  the  overall  performance  of  A5.  More  importantly,  applications 
can  specify  custom  Intents  [4],  which  may  not  be  known  a  priori.  Figure  7  depicts  the  creation  and  receipt 
of  custom  Intent,  some  .  custom .  intent .  FOO.  For  these  reasons,  A5  employs  a  more  granular  system, 
precisely  issuing  Intents  derived  from  static  analysis. 

Some  Intents  do  not  require  any  additional  information.  Sending  the  BOOT_COMPLETED  Intent  unam¬ 
biguously  indicates  that  the  device  has  finished  its  startup  procedures.  Other  Intents  lose  meaning  without 
additional  information.  For  instance,  consider  a  text  message  (SMS),  which  requires  associated  telephone 
numbers  and  message  content.  In  order  to  handle  these  more  complex  situations,  A5  uses  a  custom  library, 
libintent,  to  create  Intents  that  consist  of  well-formed  data.  Continuing  with  the  SMS  example,  when  static 
analysis  has  indicated  that  an  application  may  receive  an  SMS,  A5  uses  libintent  to  send  text  messages 
via  ADB  to  the  device  with  random  message  content  and  random,  valid  10-digit  telephone  numbers  as 
the  source.  In  A5’s  current  implementation,  libintent  handles  SMS  messages,  power  events,  battery  level 
changes,  network  events  (delay,  speed,  cellular  type,  etc),  GPS  data.  Voice  calls,  and  the  ability  to  pass 
through  generic  events  in  case  users  wish  to  use  libintent  independently  from  A5. 

The  final  method  of  interaction  is  via  a  software  feature  known  as  a  “monkey.”  Android’s  developer 
software  distribution  contains  a  program  named  monkey  for  use  in  user  interface  testing.  The  monkey 
program  “generates  pseudo-random  streams  of  user  events  such  as  clicks,  touches,  or  gestures,  as  well  as 
a  number  of  system-level  events”  [4].  By  using  the  monkey,  A5  can  automatically  simulate  user  input. 


1  Intent  i  =  new  Intent () ; 

2  i.setAction(  some  .custom,  intent  .FOO)  ; 

3  context . sendBroadcast  ( i )  ; 

4 

5  public  class  IncomingRecei ver  extends  BroadcastRecei ver  { 

6  public  void  onReceive  ( Context  context,  Intent  intent)  { 

7  if  (  i  nt  e  n  t  .  get  Action  ().  equal  s  ( some  .  custom  .  i  n  te  nt  .FOO) )  { 

8  //some  action 

9  } 

10  } 

11  } 


Figure  7:  An  example  of  a  custom  Intent,  line  2.  A  broadcastReceiver  as  defined  in  lines  5-11  can  receive  such  an 
Intent  by  observing  the  custom  string  in  the  Intent’s  action  (line  7). 


This  rather  eoarse  method  of  interaeting  with  the  applieation  ean  ehange  the  state  of  the  installed  program, 
possibly  making  the  instanee  more  likely  to  respond  to  interaetion.  For  instanee,  eonsider  an  applieation 
that  bloeks  aeeess  using  a  modal  dialog  with  a  EULA.  A  monkey  may  be  invoked  to  “eliek”  many  times, 
bypassing  the  aeeess  restrietion. 

3.7  Network  Traffic 

Any  network  eommunieation  destined  for  the  Internet  from  an  instanee  is  routed  to  the  Internet  by  A5.  This 
is  a  design  deeision  that  permits  malware  that  eonneets  to  remote  servers  to  eommunieate  with  these  servers 
so  that  the  network  traffie  ean  be  eaptured  and  used  to  inform  network  eountermeasures.  Other  eommereial 
and  aeademie  sandbox  systems  operate  in  a  similar  fashion.  Some  systems  seleetively  route  some  traffie  to 
the  Internet  and  direet  other  traffie  fo  eonfrolled  servers  or  honeypofs  [6]. 

For  virfual  insfanees,  A5  utilizes  fhe  nefwork  eapfure  fealure  of  fhe  emulator.  Using  fhe  emulator  feafure 
is  nol  only  eonvenienf  fo  inifiafe,  buf  also  resulfs  in  a  single  dafa  file  for  eaeh  inpuf  sample. 

For  physieal  insfanees,  fhe  deviees  are  eonneefed  fo  a  Wi-Fi  nefwork  whieh  is  monitored.  Unlike  fhe 
emulator  fealure,  nefwork  eapfure  is  performed  on  a  shared  medium.  To  oblain  deviee-speeifie  dafa,  fhe 
nefwork  eapfure  is  tillered  using  fhe  deviee’s  MAC  address. 

Regardless  of  fhe  inslanee  fype,  fhe  resulling  eapfure  tile  will  eonlain  a  eombinalion  of  malieious  Iraftie, 
adminislralive  Iraftie  (sueh  as  ADB),  and,  in  fhe  ease  of  repaekaged  appliealions,  legifimale  Iraftie.  Eaeh  of 
whieh  presenls  a  unique  problem  wilh  regard  fo  fhe  erealion  of  nefwork  eounlermeasures.  The  administrative 
traffie  is  generally  very  easy  fo  tiller.  Eor  example,  ADB  Iraftie  ean  lypieally  be  tillered  based  on  fhe  TCP 
porl.  Sinee  fhe  ADB  porls  vary  by  fhe  inslanlialing  of  eaeh  inslanee,  if  is  unlikely  lhaf  a  TCP  porf-based 
tiller  will  omil  any  dafa  erroneously.  This  simple  tiller  ean  reduee  fhe  nefwork  eapfure  subslanlially.  Eor 
inslanee,  tillering  ADB  Iraftie  reduees  fhe  nefwork  eapfure  for  fhe  “NolCompalible”  pieee  of  malware  [26] 
by  65%. 

Unforfunalely,  tillering  legifimale  Iraftie  is  more  diftieull  as  fhe  eharaelerislies  of  fhe  legifimale  Iraftie  are 
nol  known  a  priori.  Repaekaging  of  appliealions  in  order  fo  add  malieious  funelionalily  ereales  addilional 
diftieully.  One  mighl  imagine  learning  algorilhms  lhaf  observe  similar  behavior  aeross  a  family  of  malware. 
However,  wilh  repaekaging,  fhe  shared  behavior  may  be  fhe  legifimale  Iraftie  from  fhe  original  applieation 
or  if  may  indieafe  fhe  same  malieious  soflware  was  injeeled  info  several  differenl  appliealions. 

In  fhe  eurrenl  implemenlalion  of  A5,  fhe  nefwork  eaplures  are  pruned  sueh  lhaf  mueh  of  fhe  Iraftie  lhaf 
is  nol  benetieial  to  nefwork  eounlermeasures  is  tillered  oul.  Erom  fhe  nefwork  eaplures,  analysis  ean  fhen 


1  alert  tcp  any  any  — >  any  any  ( msg:  ”  an  tocre  a  ted  dns— >host  rule”;  content:” 

Host|3A20|”;  content: ’’notcompatibleapp  .  eu  .  |  OD  0A|”;  within:64;) 

2  alert  udp  any  any  — >  any  53  ( msg:  ”  au  tocre  a  ted  dns— >dns  rule”;  content:” 

notcompatibleapp  .  eu  ;  nocase;) 

3  alert  udp  any  any  — >  any  53  ( msg:  ”  au  tocre  a  ted  NotCompatible  data  decryptor”; 

content: ’’notcompatibleapp  .eu”;  nocase  ;) 

4  alert  udp  any  any  — >  any  53  ( msg:  ”  au  tocre  a  ted  NotCompatible  data  decryptor”; 

content: ”3na3budet9 .ru”;  nocase ;) 

5  alert  tcp  any  any  — >  any  8014  ( msg:  ”  au  tocre  a  ted  NotCompatible  data  decryptor 

”;  flow:established,  to_server;  dsize:13;  content:”  |04|”;  depth:l; 
content:”|01  05  00  00  00  00  07  00|”;) 


Figure  8:  Candidate  Snort  signatures  automatically  created  by  A5’s  post-analysis  framework  following  the  analysis 
of  a  NotCompatible  sample.  Lines  1  and  2  were  created  by  default  plugins,  whereas  lines  3-5  were  created  by  a 
custom  plugin  designed  specifically  for  the  NotCompatible  malware  family. 


create,  for  instance,  intrusion  detection  system  signatures;  while  the  process  is  not  entirely  automated,  A5 
facilitates  this  through  an  extensible  plugin  framework. 

3.8  Plugin  Framework 

A5  further  assists  the  analyst  through  a  modular  post-analysis  framework.  Plugins  are  Python  scripts  that 
follow  a  naming  convention  and  conform  to  a  simple  API,  requiring  each  plugin  to  only  define  a  handful 
of  functions  and  follow  a  naming  convention.  Each  plugin  is  loaded  dynamically  by  A5  during  malware 
execution  and  evaluated  against  dynamic  analysis  results  or  submitted  samples,  or  both.  Plugins  generate 
two  types  of  output,  signatures  intended  to  be  used  in  an  IDS,  and  freeform  text  that  is  intended  to  provide 
additional  context  to  an  A5  report.  An  analyst  can  elect  to  deploy  any  suggested  signatures  in  light  of  the 
A5  report  including  any  information  added  by  plugins. 

The  default  plugins  create  candidate  signatures  blindly — that  is,  without  having  any  prior  knowledge 
of  the  malware.  For  example,  malware  may  issue  a  DNS  query  in  order  to  determine  the  IP  address  of 
a  Command-and-Control  server.  A  perfectly  acceptable  IDS  signature  may  look  for  this  particular  DNS 
query  and  block  the  communication,  thus  preventing  the  malware  from  further  interaction  with  the  remote 
controller.  On  the  other  hand,  a  DNS  query  may  be  legitimate  traffic  issues  wifh  fhe  purpose  of  defermining 
fhe  IP  address  of  a  server  fhaf  is  used  fo  save  high  score  dafa  in  a  game.  Defaull  plugins  are  a  simple  affempf 
fo  aufomafe  fhe  analysf’s  work  when  a  sample  has  never  before  been  encountered  by  A5.  Since  fhe  defaull 
plugins  are  fairly  generic,  Ihey  may  have  limited  value,  bul  Ihey  do  aufomafe  fhe  signalure  creation  process 
and  may  help  prevenf  cosily  typographical  mislakes  in  signalure  crealion. 

Unlike  newly  encounfered  malware,  fhe  plugin  framework  can  also  be  employed  fo  automate  signalure 
crealion  for  known  malware  families.  The  framework  facililales  programmatic  access  to  Ihe  dala  collected 
during  dynamic  analysis  and  Ihe  associated  Android  application.  In  Ibis  way,  malware  can  be  identified 
using  Ihe  submilling  application,  or  via  caplured  Iraflic,  or  bolh.  Subsequenlly,  prior  knowledge  can  be 
applied  to  new  varianls  of  malware  to  automate  many  analysis  lasks. 

As  we  will  show  in  4,  a  plugin  can  be  used  to  automate  specific  identification,  dala  exlraclion,  decryption, 
and  Ihe  crafting  of  IDS  rules  well  suited  for  a  malware  family.  A5  plugins  provide  a  general  melhod  of 
applying  actions  lhal  may  olherwise  lake  considerable  time  for  an  analyst 

We  provide  an  example  of  candidate  signalures  created  by  Ihe  posl-analysis  framework  in  Figure  8. 
While  Ihe  plugin  here  creates  Snorl  signalures,  olher  IDS  (e.g.,  Bro)  could  be  supported  in  a  similar  manner. 


The  signatures  have  been  automatically  created  from  the  dynamic  analysis  of  the  NotCompatible  mal¬ 
ware  [26].  An  analyst  would  still  be  charged  with  identifying  that  the  candidate  on  line  1  is  likely  of  little 
value,  but  that  lines  2-5  may  be  useful.  Lines  1  and  2  were  created  by  default  plugins  that  assume  that  DNS 
queries  still  present  in  the  pruned  network  traces  search  for  malicious  domains,  and  thus  a  DNS  based  rule 
or  an  HTTP  rule  based  on  the  DNS  name  may  be  useful.  However,  the  NotCompatible  malware  doesn’t  use 
the  HTTP  protocol,  so  a  signature  looking  for  a  Host  header  is  not  relevant. 

The  real  power  of  the  plugin  framework  is  actually  more  evident  in  lines  3-5.  Rather  than  a  specific 
piece  of  malware,  NotCompatible  actually  defines  a  family  of  related  pieces  of  malware — we  have  observed 
dozens  of  differenl  samples  in  fhe  wild.  Using  a  previously  seen  varianf  of  NofCompafible,  our  plugin  was 
able  fo  produce  a  cusfom  rule  for  fhis  (unseen  before)  varianf  of  NofCompafible  in  lines  3-5.  In  ofher  words, 
our  plugin  is  able  fo  aufomafically  generate  IDS  signafures  for  new  varianfs  of  NofCompafible  as  long  as 
fhe  overall  nefworking  profocol  used  in  fhe  malware  family  does  nof  change. 

More  precisely,  fhe  plugin,  whose  source  can  be  found  in  fhe  appendix,  idenfifies  NofCompafible  mal¬ 
ware  based  on  fhe  unique  nefworking  profocol  employed  by  fhe  malware.  Once  fhe  malware  is  identified, 
fhe  plugin  can  fhen  automatically  decrypf  fhe  command-and-confrol  server  dafa  stored  in  fhe  APK.  This  is 
very  useful  for  fhe  analysf  since  fhe  dynamic  analysis  sysfem  is  likely  to  only  creafe  nefwork  Iraffic  fo  fhe 
initial  command-and-confrol  server,  Iherefore  never  having  to  resort  fo  fhe  backup  server. 

4  Evaluation 

Here  we  evaluate  an  implemenfafion  of  A5.  We  evaluafe  our  design  goals  wifh  fhe  specific  implemenfafion, 
measure  performance  of  fhe  sysfem,  and  compare  A5  wifh  an  exisfing  Android  runtime  analysis  sysfem. 

4.1  Design  Goals 

In  section  3.1,  we  enumerafed  five  criteria  fhaf  our  A5  musf  embody  in  order  fo  be  a  successful  sandbox. 
Here  we  discuss  how  A5  fulfills  each  of  fhese  mefrics  in  furn. 

Autonomy  and  scalability.  A5’s  disfribufed  and  expandable  archifecfure  permif  A5  to  grow  linearly  wifh 
fhe  growfh  of  mobile  malware  samples.  Addifional  Workers  can  be  added  fo  an  A5  insfallafion  by  adding 
resources  fo  an  exisfing  node  or  by  adding  addifional  nodes.  Furfher,  fhe  periodic  ingesfion  process  along 
wifh  on-demand  web  service  submission  affords  A5  fhe  Ilexibilily  of  inferacfed  wifh  a  user  dynamically  or 
aufonomously  processing  malware  feeds  wifhouf  user  inferacfion. 

Whefher  samples  are  processed  automatically  or  on-demand,  A5  affempfs  fo  ease  fhe  burden  placed  on 
fhe  analysf  by  filfering  ouf  innocuous  fraffic  and  presenfing  candidate  signafures  for  fhe  remaining  nefwork 
acfivify.  For  idenfified  malware  families,  additional  posf-processing  can  be  performed  in  order  fo  furfher 
aufomafe  analysis  and  counfermeasure  creafion.  Ulfimafely,  human  inferacfion  is  sfill  required  for  final 
determination  of  network  countermeasures,  but  this  interaction  is  substantially  less  than  if  the  analyst  had  to 
perform  any  analysis  manually. 

Mobile-specific  interaction.  The  methods  of  malware  coercion  certainly  vary  between  mobile  and  PC-centric 
malware.  Here  A5  employs  a  variety  of  mobile-specific  coercion  fechniques.  The  mosf  sfraighf-forward 
inferacfion  is  acfually  running  fhe  mobile  application.  For  mosf  applicafions,  fhe  interaction  is  similar  fo 
fhaf  of  PC-malware:  sfarfing  fhe  defaull  Android  Acfivify.  However,  fhrough  fwo  sfages  of  sfafic  analysis, 
A5  defermines  many  fypes  of  coercion  fhaf  would  ofherwise  be  omiffed  from  a  dynamic  analysis  sysfem. 
Infenfs  determined  from  sfafic  analysis  are  fhen  issued  in  an  Android  insfance  dynamically,  effecfing  fhe 
malicious  behavior. 

Evasion  resistance.  When  inferacfing  wifh  malware,  A5  lakes  steps  to  presenl  plausible  informalion  to  fhe 
application  under  evaluation.  For  insfance,  lexl  messages  appear  fo  originate  from  random,  valid  numbers. 


By  using  plausible  data  and  avoiding  predictable  data,  A5  seeks  to  be  less  identifiable  to  malware  that 
inspects  the  high  level  state  of  the  device. 

Knowing  that  virtualization  detection  has  a  mature  presence  in  targetting  other  malware  sandboxes,  it  is 
a  foregone  conclusion  that  Android  malware  will  employ  similar  tactics.  Therefore,  virtual  instances  used  in 
A5  employ  a  modified  Android  emulafor  fhaf  fakes  sfeps  fo  hide  if’s  virfual  nafure  by  embodying  program- 
mafic  characferisfics  of  a  physical  device.  Even  so,  some  fypes  of  virfualizafion  defecfion  are  simply  loo 
difficull  lo  implemenl  as  a  modificalion  lo  Ihe  slandard  Android  emulafor.  A5  allows  system  implemenlers 
fo  mitigate  fhis  risk  by  using  physical  insfances  fhus  avoiding  use  of  an  emulator  alfogelher.  By  using  real 
devices,  fhe  malware  acfually  runs  on  hardware  making  sandbox  defecfion  much  more  difficull  for  malware 
aulhors. 

In  anolher  way,  A5  avoids  a  lype  of  evasion  in  lhal  malware  largeling  any  parlicular  Android  API 
version  will  run  in  A5.  If  A5  only  supporled  a  subsel  of  API  versions  Ihen  malware  mighf  nol  run  in  A5 
al  all,  rendering  no  analysis  and  effectively  evading  fhe  enlire  syslem.  By  allowing  device  pools  lo  cover 
fhe  entire  range  of  Android  APIs,  among  any  combinalion  of  virfual  and  physical  insfances,  A5  can  slarl  a 
Worker  for  any  API  version  required  by  a  particular  sample. 

Network-level  indicator  collection.  The  colleclion  of  nelwork  indicalors  is  crilical  fo  enabling  enterprises 
and  nelwork  providers  to  prolecl  Iheir  nefworks,  even  when  individual  mobile  devices  may  have  little  or  no 
securily-orienled  soflware.  For  virfual  insfances,  A5  makes  use  of  a  fealure  buill-in  to  fhe  Android  emulafor 
to  collecl  nelwork  aclivily  during  dynamic  analysis.  For  physical  insfances,  A5  makes  use  of  commodify 
nelwork  caplure  tools  use  on  a  shared  WIFI  access  poinl.  Nelwork  Iraffic  caplure  on  fhe  shared  nelwork  is 
tillered  based  on  fhe  known  MAC  addresses  of  fhe  physical  devices  inslalled  in  fhe  A5  inslance.  For  eilher 
inslance  lype,  A5  creales  candidate  nelwork  countermeasures  for  never  before  seen  samples  and  performs 
extended  posl-analysis  on  recognizable  malware  families  leading  lo  addilional  nelwork  counlermeasures. 

Modularity  A5  is  written  in  a  very  modular,  objecl-orienled  way.  Inleraclion  wilh  dependenl  soflware  (such 
as  ADB)  are  written  as  libraries  providing  a  re-usable  inlerface.  Use  of  supporl  syslems  such  as  dalabase  and 
job  queuing  are  also  done  in  very  slandard  ways  using  malure  subsyslems.  In  Ihese  ways,  A5  is  adaplable 
to  existing  research  environmenls  lhal  have  differenl  workflows  or  special  needs. 

However,  for  Ihe  general  user  of  A5,  Ihe  more  useful  form  of  modularity  come  from  Ihe  posl-analysis 
plugin  framework.  This  framework  facililales  in  automating  lasks  upon  dynamic  analysis  resulls  and  sub¬ 
mitted  malware  samples.  Plugins  can  be  used  to  automatically  create  candidate  nelwork  signalures,  decode 
sections  of  nelwork  Iraffic,  decrypl  malware  payloads,  and  any  number  of  olher  uses. 

Plugins  currenlly  implemented  in  A5  focus  on  Snorl  [24]  IDS  formal,  Ihough  modifying  for  olher  for- 
mals  is  often  merely  a  matter  of  synlax.  Since  any  given  user  may  prefer  a  particular  IDS,  each  of  which 
may  have  very  custom  synlax,  preprocessors,  configurations,  elc.  Ihe  defaull  plugins  are  likely  of  limited 
value  to  any  given  user.  However,  Ihe  modularity  of  Ihe  plugin  framework  allows  simple  creation  of  new 
plugin  such  lhal  candidate  rules  can  be  readily  deployed  to  a  particular  system. 

We  measured  A5  performance  using  1260  samples  from  Ihe  dalasel  described  by  Zhou  and  Jiang  [39]. 
The  A5  system  is  on  an  8  processor  (Intel  Xeon  E5620  @  2.4  GHz)  Finux  machine  wilh  64GB  of  RAM. 
A5  was  configured  to  use  5  Workers,  and  Ihe  arbilrary  sleep  time  for  each  sample  (see  Figure  5)  was  sel 
to  60  seconds.  The  entire  device  pool  was  sel  to  be  virfual  insfances,  wilh  Iwo  device  insfances  for  each 
SDK  version.  As  shown  in  Table  1,  Ihe  average  runtime  for  samples  was  149.1  seconds,  requiring  jusl  over 
50  hours  of  cumulative  execution  to  run  all  1260  samples  [39].  By  using  5  Workers,  Ihe  time  required  to 
process  Ihe  entire  sel  was  reduced  to  jusl  10  hours. 

Slage  1  Sialic  Analysis  performed  correclly  for  all  samples.  Slage  2  Sialic  Analysis  premalurely  termi¬ 
nated  on  10%  of  samples.  In  particular,  Ihe  DED  decompiler  [1 1]  failed  to  decompile  10%  (131)  of  samples. 
Of  Ihe  1129  applications  lhal  successfully  decompiled,  Slage  2  Analysis  discovered  Inlenls  in  4.5%  (51)  of 
samples  (14  of  50  families). 


1  12:14:56.918698  IP  10.0.2.15.22219  >  1  0 . 0 . 2 . 3  .  domain:  22666+  A? 
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Figure  9:  ASCII  representation  of  network  traffic  captured  by  A5  from  NotCompatible  malware.  NotCompatible’s 
namesake  domain  is  clearly  present  (line  1)  in  this  DNS  query  from  10.0.2.15,  an  A5  device. 


A5  Stage 

Min 

Time 

Max 

Time 

Average 

Time 

Stage  1  Static  Analysis 

1.9 

5.6 

2.6 

Stage  2  Static  Analysis 

10.0 

120.7 

12.7 

Dynamic  Analysis 

124.5 

202.3 

133.8 

Total  runtime 

136.4 

328.6 

149.1 

Table  1:  A5  runtimes  per  sample  (in  seconds).  Each  time  is  was  calculated  by  processing  the  entire  dataset  described 
by  Zhou  and  Jiang  [39]. 


We  also  analyzed  some  more  reeent  malware  using  A5  and  verified  the  results  manually.  For  example, 
NotCompatible  is  Android  malware  that  does  not  “root”  the  infeeted  deviee,  but  nonetheless  is  able  to  aet 
as  a  TCP  proxy,  tunneling  malieious  traffie  through  an  infeeted  deviee  [26].  This  malware  has  typieal  bot¬ 
net  like  features  sueh  as  the  ability  for  a  remote  aetor  to  eontrol  the  software  through  a  publiely  aeeessible 
server,  known  as  a  eommand-and-eontrol  server.  A5  was  able  to  identify  remote  servers  assoeiated  with 
NotCompatible  malware.  The  primary  remote  server  was  immediately  observable  in  the  DNS  request  (Fig¬ 
ure  9)  and  subsequent  malware  eommunieation.  Manual  statie  analysis  also  revealed  the  remote  address,  but 
required  signifieant  time  to  understand  the  Dalvik  elasses  and  required  deerypting  a  data  file.  One  operation 
of  the  NotCompatible  malware  allows  a  remote  server  to  update  the  remote  destination  address,  so  the  next 
remote  eommunieation  would  happen  with  a  different  server.  Statie  analysis  would  not  be  able  to  diseern 
this  next  server  address. 

The  NotCompatible  malware  also  highlights  the  usefulness  of  A5’s  Android- speeitie  eoereion  teeh- 
niques.  NotCompatible  malware  does  not  exeeute  upon  installation.  Instead,  the  malware  waits  for  eertain 
system  events,  namely  BOOT.COMPLETED  or  USER.PRESENT.  In  other  words,  NotCompatible’s  mali¬ 
eious  serviee  will  only  start  when  the  deviee  is  rebooted,  or  when  the  user  unloeks  the  deviee’s  sereen  loek. 
A5  is  able  to  determine  the  neeessity  to  mimie  these  events  and  sueeessfully  eoeree  the  malware. 

The  post-analysis  plugin  is  useful  to  ereate  the  eandidate  signatures  (shown  earlier  in  Figure  8).  In 
this  ease,  the  plugin  automatieally  determines  that,  in  addition  to  the  traffie  observed  to  the  primary 
server,  notcompatibleapp .  eu,  other  infeeted  deviees  may  attempt  to  eonneet  to  the  baekup  domain 
3na3budet9  .  ru,  whieh  is  enerypted  and  stored  within  the  malware.  This  speeffie  sample  uses  TCP  port 
8014  on  both  servers,  whieh  A5  was  able  to  automatieally  deteet,  and  ereate  IDS  rules,  based  on  the  generie 
template  ereated  from  a  higher-level  deseription  of  the  malware  family. 


4.2  Existing  sandbox  comparison 


In  order  to  highlight  some  of  A5’s  advaneements  we  ean  evaluate  some  metries  with  another  Android  sand¬ 
box.  Unfortunately  the  souree  eode  and  design  of  other  sandboxes  are  not  publiely  available,  so  for  eom- 
parison,  we  submitted  samples  to  Andrubis  via  its  web  interfaee  [2].  We  observe  that  when  a  sample  is 
submitted,  the  estimated  job  eompletion  time  is  always  reported  to  be  about  eight  minutes.  If  we  submit 
samples  very  quiekly,  multiple  submissions  queue  sequentially  eausing  a  delay  before  the  submitted  sample 
is  proeessed,  indieating  that  Andrubis  does  not  proeess  samples  in  parallel.  For  this  reason,  we  purposefully 
submitted  samples  one  at  a  time,  waiting  for  a  eurrent  sample  to  eomplete  before  submitting  another.  Even 
though  this  is  a  publie  web  serviee,  we  did  not  observe  any  other  user  of  Andrubis  during  out  testing. 

We  ereated  an  Android  applieation  that  extraeted  virtualization  information  mentioned  in  4.1.  Namely, 
the  Android  Build  strings  and  TelephonyManager  identifies  Andrubis’  runtime  software  as  an  Android 
emulator.  From  this,  we  eonelude  that  Andrubis  does  not  appear  to  employ  physieal  deviees  nor  emulator 
deteetion  mitigations.  We  also  submitted  a  seeond  applieation  that  was  identieal  to  this  first  applieation 
exeept  for  an  appended  null  byte  in  order  to  give  the  otherwise  identieal  applieation  a  different  file  size  and 
assoeiated  eryptographie  hash.  This  was  meant  to  ensure  that  submitted  applieations  are  aetually  exeeuted 
by  Andrubis  and  to  observe  similarity  between  two  similar  samples  submissions.  The  reports  were  very 
similar  even  though  exeeution  time  for  the  two  samples  were  reported  to  be  227  seeonds  and  337  seeonds 
respeetively,  so  there  is  some  varianee  in  Andrubis’  applieation  runtime. 

We  then  ereated  14  variations  of  the  test  Android  applieation,  eaeh  different  only  in  that  the  settings 
for  minimum,  maximum  and  target  SDK  as  eonfigured  in  the  AndroidManif est  .xml.  It  seems  that 
Andrubis  only  supports  a  subset  of  Android  SDK  versions  supported  by  TaintDroid,  namely  2.1  and  2.3. 
For  example,  submitting  an  APK  with  the  minimum,  maximum  and  target  SDK  eaeh  set  to  8,  denoting 
Android  2.2,  in  the  AndroidManifest  eauses  dynamie  analysis  to  fail.  Andrubis  fails  in  this  way  for  many 
eombinations  of  SDK  values  eausing  the  sample  to  not  be  analyzed  at  all. 

Another  differenee  is  that  Andrubis  does  not  appear  to  use  the  statie  analysis  portions  to  inform  the  dy¬ 
namie  analysis.  This  is  easily  evideneed  by  submitting  an  applieation  that  takes  no  aetion  exeept  upon  some 
other,  outside  event,  sueh  as  the  reeeipt  of  a  text  message,  or  aetivation  of  the  sereen  loek.  Unfortunately, 
this  means  that  for  malware  like  NotCompatible,  Andrubis  will  not  observe  any  of  the  malieious  behavior. 

In  praetiee,  Andrubis  often  does  not  start  proeessing  samples  immediately,  in  faet,  only  onee  did  a 
sample  start  proeessing  immediately.  Instead,  of  the  15  submissions,  Andrubis  reported  an  average  delay  of 
92  minutes  (min:  immediate,  max:  16  hours).  Overall,  the  exeeution  time  aeross  our  submissions  averaged 
253  seeonds  (min:227,  max:337  seeonds).  Given  that  both  Andrubis  and  A5  must  ineorporate  eertain  delay 
in  dynamie  proeessing,  the  differenee  in  average  runtime  is  not  signifieant. 

As  a  final  differenee,  A5  reports  eontain  only  meta  information  about  the  sample,  but  also  eontain  IDS 
signature  eandidates.  In  this  way  A5  provides  immediately  aetionable  results.  Conversely,  Andrubis  reports 
do  not  eontain  IDS  signatures  and  may  require  more  evaluation  from  an  analyst,  who  then  must  manually 
ereate  IDS  signatures. 

5  Limitations 

In  seetion  3,  we  detailed  several  eomponents  of  our  analysis  system.  Design  deeisions  and  implementation 
ehoiees  affeet  the  eapabilities  of  eaeh  of  these  eomponents.  Here  we  address  the  eurrent  limitations  for  eaeh 
eomponent  of  A5. 


5.1  Static  Analysis 


In  addition  to  general  limitations  of  dynamie  analysis  systems,  A5  has  several  additional  limitations.  In 
statie  analysis,  A5  depends  upon  tools  sueh  as  Androguard  [1]  and  Soot  [30].  Defieieneies  in  these  tools 
may  also  manifest  in  A5. 

The  byteeode  statie  analysis  is  limited  to  finding  only  behaviors  that  are  statieally  defined  and  ex- 
fraefable  from  fhe  byfeeode  ifself.  For  insfanee,  a  given  applieafion  eomponenf  sueh  as  an  Aefivify  is 
sfarfed  eifher  by  fhe  Android  middleware,  or  by  anofher  applieafion,  by  sending  an  appropriafe  Infenf  fo 
fhe  applieafion.  Ideally,  we  would  wanf  fo  know  all  Infenfs  reeeivable  by  fhe  applieafion,  so  we  ean  eoeree 
ifs  behavior.  Unforfunafely,  for  mefhods  whieh  reeeive  Infenfs,  fhe  mefhod  is  provided  fhe  Infenf  via  an 
android .  content .  Intent  objeef,  whieh  eonfains  a  siring  wifh  fhe  name  of  fhe  Infenf  used  fo  frigger 
fhe  fargef  applieafion.  As  fhe  value  in  fhis  siring  is  filled  in  dynamieally  al  runtime  when  fhe  Infenf  is  ereafed, 
A5  is  unable  fo  slalieally  determine  fhe  siring  eonlenl.  In  order  fo  slalieally  identify  fhe  Infenf  lhal  Iriggered 
fhe  aefivify  or  olher  applieafion  eomponenf,  every  Infenf  would  need  fo  be  of  a  differenl  lype  whieh  is  slal¬ 
ieally  specified.  However,  fhis  is  nol  fhe  case,  and  A5  is  unable  fo  exlracl  or  identify  Infenfs  received  by 
receivers.  Hence,  fhe  byfeeode  sialic  analysis  is  able  fo  exlracl  only  Infenfs  which  fhe  application  regislers 
fo  receive,  as  fhe  Infenf  aclion  siring  is  sel  slalieally  when  notifying  fhe  syslem  of  fhe  Infenfs  fo  receive. 

The  Iraversal  of  fhe  CFG  is  infra-procedural,  and  fhe  CFG  analysis  is  fiow-insensifive  meaning  all 
branches  and  loops  are  ignored.  While  Ibis  a  priori  could  resull  in  unsound  analysis,  fhis  has  nol  been 
an  issue  in  fhe  conlexl  of  A5.  Indeed,  fhe  Iwo  lypes  of  inferaclion  poinls  currenlly  soughl  are  mefhod  in- 
vocalions  and  inferaclion  poinls  are  exlracfed  by  observing  fhe  values  of  argumenfs  passed  fo  fhe  mefhod. 
Typically,  fhe  argumenl  conslruclion  leading  fo  fhe  mefhod  invocation  would  be  linear  code  in  fhe  same 
basic  block  wilhoul  any  condilional  slalemenls.  In  fhis  case,  llow-insensilive  analysis  would  be  sufficienl 
for  analysis.  Flow-insensilive  analysis  may  also  inlroduce  false  positives.  However,  since  in  fhe  case  of 
additional  false  posilives  fhe  malware  coercion  would  only  require  a  subsel  of  idenlified  inleraclions  which 
would  resull  in  effeclive  coercion.  The  primary  issue  wifh  false  posilives  is  decreased  performance  due  fo 
unnecessary  coercion. 

In  addition,  by  virlue  of  sialic  analysis  being  sialic,  any  dynamically  received  code  updates  by  fhe  appli- 
calion  cannol  be  analyzed.  For  insfanee,  fhe  sialic  analysis  will  have  no  access  fo  byfeeode  or  Java/Dalvik 
classes  received  al  runlime  and  subsequenlly  executed.  However,  A5’s  dynamic-analysis  phase  will  slill  be 
able  fo  collecl  nelwork  indicators  of  fhe  dynamically  executed  code.  This  lype  of  update  attack  [39]  has 
been  detected  in  malware  in  fhe  wild, 

5.2  Dynamic  Analysis 

A5  exhibils  well-known  limilalions  similar  to  any  dynamic  analysis  system.  For  example,  if  fhe  malware  be¬ 
havior  changes  based  on  lime  of  day,  fhe  success  of  A5  would  depend  greally  on  when  fhe  sample  happened 
to  be  selected  by  a  Worker.  Similarly,  if  malware  largels  a  specific  manufaclurer  olher  lhan  fhe  manufaclurer 
employed  in  dynamic  analysis,  fhe  malware  may  exhibif  allernale  behavior  during  analysis.  Generally,  if 
is  jusl  nol  possible  fo  ensure  lhal  all  possible  funclionalily  of  a  sample  is  explored  during  execution  [14]. 
As  wifh  any  sandbox  syslem,  fhe  primary  use  is  to  quickly  process  volumes  of  malware  -  handling  mosl 
samples  correclly,  nol  focusing  on  individual  accuracy  of  a  given  sample. 

There  is  some  evidence  lhal  randomly  issuing  inpuf  fo  fhe  user  inlerface  may  nol  yield  successful  resulls 
[18].  Gilberl  el  al.  conclude  lhal  random  inpul,  as  is  expecled  from  an  Android  Monkey,  may  yield  as 
low  as  40%  coverage  of  all  possible  UI  inpul.  On  fhe  olher  hand,  more  slruclured  inpul  is  explored  by 
Zheng  el  al.  [38]  which  exhibils  ifs  own  drawbacks,  in  parlicular  fhe  inabilily  fo  handle  cerlain  logic  when 
inleracling  wifh  fhe  UI.  This  parlicular  implemenlafion  [38]  has  olher  drawbacks,  bul  many  can  likely  be 
overcome.  Much  as  fhe  hybrid  sialic  and  dynamic  analysis  employed  by  A5,  fhe  besl  UI  inferaclion  is  likely 


a  combination  of  random  and  structured  input.  Additionally,  new  methods  of  UI  interaction  are  increasingly 
available  as  Android’s  SDK  evolves.  Devices  using  API  16  or  higher  have  a  “Dump  view  hierarchy”  that 
could  be  used  to  inform  a  UI  automaton  This  hierarchy  presents  a  tree  of  UI  components  that  could  be 
traversed  as  part  of  dynamic  analysis.  Continuing  with  the  previous  example  of  the  EULA  modal  dialog, 
using  such  a  UI  automator  could  enable  a  dynamic  system  to  precisely  “click”  an  accept  button  instead  of 
randomly  happening  to  “click”  the  screen  in  a  correct  location. 

In  practice,  ADB  is  not  reliable,  often  not  performing  the  desired  action,  yet  returning  a  successful 
return  code.  In  order  to  perform  in  lieu  of  these  faults,  A5  monitors  ADB  execution  repeating  actions  until 
the  desired  effect  is  observed. 


6  Conclusions 

We  have  presented  a  system,  A5,  to  completely  automate  the  dynamic  execution  of  Android  malware.  Our 
system  extracts  information  from  the  malware  prior  to  execution  in  order  to  better  understand  how  to  interact 
with  the  malware.  In  this  way,  A5  is  able  to  better  coerce  malicious  behavior  from  the  malware  and  ulti¬ 
mately  capture  network  threat  indicators.  These  indicators  can  be  used  simply  to  quickly,  better  understand 
the  malware,  and  to  inform  network-oriented  countermeasures. 

The  implementation  we  have  described  uses  novel  methods  of  interacting  with  mobile  applications, 
extracting  interaction  points  during  static  analysis  to  inform  the  dynamic  analysis  process. 

The  distributed,  parallel  design  of  A5  allows  instances  to  scale  with  the  growth  of  mobile  malware.  A5 
is  not  only  highly  parallel  but  also  modular  in  design,  allowing  wholesale  replacement  of  components  in 
favor  of  newer,  better  performing  options. 

Any  sandbox  implementation  for  Android  must  be  aware  that  current  virtualization  capabilities  are  in¬ 
complete,  and  analysis  will  likely  soon  encounter  malware  that  employs  virtualization  detection  techniques. 
A5  aims  to  partially  address  this  issue  both  by  making  virtual  instances  more  evasion-resistant  and  by  having 
the  flexibility  to  use  actual  physical  devices  during  dynamic  analysis. 

We  also  presented  performance  measurements  of  a  specific  implementation  of  A5  using  a  public  dataset 
of  1,260  unique  Android  malware  samples.  On  modest  hardware,  the  implementation  was  able  to  process 
the  malware  set  averaging  149  seconds  per  sample. 

A5  represents  a  new  generation  of  automated  analysis  able  to  cope  with  large  volumes  of  mobile  mal¬ 
ware.  A5  is  able  to  better  coerce  malicious  behavior  by  interacting  with  mobile  malware  in  mobile-specific 
ways.  By  focusing  on  network  threat  indicators,  A5  is  immediately  useful  to  cellular  providers  and  operators 
of  wireless  networks. 

An  implementation  of  A5  is  publicly  available  at  http  :  /  /dogo  .  ece  .  emu  .  edu/a5. 
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A  NotCompatible  A5  plugin 


tfilenames  for  plugins  must  start  with  the  string  "plugin_"  and  end  in  ".py" 

tplugins  always  return  a  tuple  (pluginName, listOfCountermeasures, listOfComments) 
twhere  the  first  value  is  a  string  and  the  second  two  are  each  a  python  List 
#plugins  should  have  no  printed  output 

tpluginName  is  a  required  variable  for  plugins 

#this  is  simply  a  name  for  the  plugin  that  is  used  in  logging  and  stdout 

pluginName  =  "NotCompatible  data  decyptor" 

#if  true,  the  plugin  will  be  used,  if  false  it  will  not 
enable  =  True 

#type  is  a  required  variable  for  plugins 

#type  is  simply  a  string  that  is  used  to  group  plugins  by  category, 
fused  for  unit  testing,  in  production  the  type  often  doesn't  matter 
type  =  "known" 

flogger  is  optional,  if  the  plugin  requests  a  logger  like  this,  logging  entries  will  end  up  in  the  si 
fimport  logging 

flogger  =  logging . getLogger ( _ name _ ) 

class  PluginClass: 

msg  =  "autocreated  NotCompatible  data  decryptor" 
def  get_dns_rule (self ,  domain)  : 

return  ('alert  udp  any  any  ->  any  53  (msg:"%s";  content : "%s " ;  nocase;)' 

%  (self .msg, domain) ) 

def  get_notc_rule (self , port) : 

return  ('alert  tcp  any  any  ->  any  %s  (msg:"%s";  flow : established, 
to_server;  dsize:13;  content :" | 04 | " ;  depth:l; 
content:" I  01  05  00  00  00  00  07  00 |";)'  %  (port, self .msg) ) 

def  run (self , pcap, apk) : 
ruleList  =  list() 
commentList  =  list() 

if  pcap  is  None  or  apk  is  None: 

commentList . append ( "this  plugin  requires  a  pcap  file  and  an  apk  to  work") 
logger . error ( "plugin  requires  a  pcap  and  an  apk... but  didn't  get  em" ) 
return  (pluginName, None, commentList) 

try : 

from  scapy.all  import  PcapReader , hexdump, Is 
import  sys 

my_reader  =  PcapReader (pcap) 

if  ( self . f indNotCompatiblePhoneHome (my_reader ) )  : 

pt  =  self . decryptNotCompatibleData (apk, ruleList , commentList ) 

(primary , secondary , pport , sport )  =  pt . split  ('  | ' ) 

commentList . append ( "new  notcompatible  sockets:  %s:%s  ,  %s:%s"  %  (primary, pport, 
secondary, sport) ) 

ruleList . append (self . get_dns_rule (primary) ) 
ruleList . append (self . get_dns_rule (secondary) ) 
ruleList . append ( self . get_notc_rule (pport ) ) 


ruleList . append ( self . get_notc_rule (sport ) ) 
except  lOError: 

logger . error { "Failed  reading  pcap") 
return  (pluginName,  None,  None) 

return  (pluginName,  ruleList,  commentList) 
def  decrypt ( self , passkey , param) : 

from  Crypto. Hash  import  SHA256 
from  Crypto . Cipher  import  AES 
keyhash  =  SHA256 . new (passkey) 
key  =  keyhash . digest ( ) 

cipher  =  AES . new (str (key) ,  AES .MODE_ECB,  "ignored") 

buf  =  buffer (param, 0 , len (param) ) 
return  cipher . decrypt (buf ) 

def  decryptNotCompatibleData ( self , apk, rules , comments ) : 
from  soapy. all  import  hexdump 

fdirectly  from  the  zip  (relies  upon  working  zip  imlementation  in  python!) 
import  zipfile 

file  =  zipfile . ZipFile (apk, "r" ) 
data  =  file . read (" res/raw/data" ) 

key  =  "ZTY4MGE5YQO" 

comments . append ( "key :  %s"  %  key) 

plaintext  =  self . decrypt (key,  data) 

comment s . append ( "decrypted :  %s"  %  plaintext) 

return  plaintext 

def  findNotCompatiblePhoneHome (self ,  reader)  : 
from  soapy. all  import  TCP , Raw, hexdump 
for  pkt  in  reader: 

if  pkt . haslayer (TCP ) : 
if  pkt . haslayer (Raw) : 

data  =  pkt . getlayer (Raw) . load 
if  len(data)  ==  13: 
if  data [0]  ==  ' \x04' : 

initialcall  =  bytearray . f romhex ( " 01  05  00  00  00") 
if  data[3:8]  ==  initialcall: 
return  True 


return  False 


